The present invention is directed to a method, system, and architecture for streaming applications from a server for execution on a client, and, more particularly, a method and system for executing streamed applications on a client system.
The Internet, and particularly the world-wide-web, is a rapidly growing network of interconnected computers from which users can access a wide variety of information. Initial widespread use of the Internet was limited to the delivery of static information. A newly developing area of functionality is the delivery and execution of complex software applications via the Internet. There are two basic techniques for software delivery, remote execution and local delivery, e.g., by downloading.
In a remote execution embodiment, a user accesses software which is loaded and executed on a remote server under the control of the user. One simple example is the use of Internet-accessible CGI programs which are executed by Internet servers based on data entered by a client. A more complex systems is the Win-to-Net system provided by Menta Software. This system delivers client software to the user which is used to create a Microsoft Windows style application window on the client machine. The client software interacts with an application program executing on the server and displays a window which corresponds to one which would be shown if the application were installed locally. The client software is further configured to direct certain I/O operations, such as printing a file, to the client""s system, to replicate the xe2x80x9cfeelxe2x80x9d of a locally running application. Other remote-access systems, such as provided by Citrix Systems, are accessed through a conventional Internet Browser and present the user with a xe2x80x9cremote desktopxe2x80x9d generated by a host computer which is used to execute the software.
Because the applications are already installed on the server system, remote execution permits the user to access the programs without transferring a large amount of data. However, this type of implementation requires the supported software to be installed on the server. Thus, the server must utilize an operating system which is suitable for the hosted software. In addition, the server must support separately executing program threads for each user of the hosted software. For complex software packages, the necessary resources can be significant, limiting both the number of concurrent users of the software and the number of separate applications which can be provided.
In a local delivery embodiment, the desired application is packaged and downloaded to the user""s computer. Preferably, the applications are delivered and installed as appropriate using automated processes. After installation, the application is executed. Various techniques have been employed to improve the delivery of software, particularly in the automated selection of the proper software components to install and initiation of automatic software downloads. In one technique, an application program is broken into parts at natural division points, such as individual data and library files, class definitions, etc., and each component is specially tagged by the program developer to identify the various program components, specify which components are dependent upon each other, and define the various component sets which are needed for different versions of the application.
Once such tagging format is defined in the Open Software Description (xe2x80x9cOSDxe2x80x9d) specification, jointly submitted to the World Wide Web Consortium by Marimba Incorporated and Microsoft Corporation on Aug. 13, 1999. Defined OSD information can be used by various xe2x80x9cpushxe2x80x9d applications or other software distribution environments, such as Marimba""s Castanet product, to automatically trigger downloads of software and ensure that only the needed software components are downloaded in accordance with data describing which software elements a particular version of an application depends on.
Although on-demand local delivery and execution of software using OSD/push techniques is feasible for small programs, such as simple Java applets, for large applications, the download time can be prohibitively long. Thus, while suitable for software maintenance, this system is impractical for providing local application services on-demand because of the potentially long time between when the download begins and the software begins local execution.
Recently, attempts have been made to use streaming technology to deliver software to permit an application to begin executing before it has been completely downloaded. Streaming technology was initially developed to deliver audio and video information in a manner which allowed the information to be output without waiting for the complete data file to download. For example, a full-motion video can be sent from a server to a client as a linear stream of frames instead of a complete video file. As each frame arrives at the client, it can be displayed to create a real-time full-motion video display. However, unlike the linear sequences of data presented in audio and video, the components of a software application may be executed in sequences which vary according to user input and other factors.
To address this issue, as well as other deficiencies in prior data streaming and local software delivery systems, an improved technique of delivering applications to a client for local execution has been developed. This technique is described in parent U.S. patent application Ser. No. 09/120,575, entitled xe2x80x9cStreaming Modulesxe2x80x9d and filed on Jul. 22, 1998, now U.S. Pat. No. 6,311,221.
In a particular embodiment of the xe2x80x9cStreaming Modulesxe2x80x9d system, a computer application is divided into a set of modules, such as the various Java classes and data sets which comprise a Java applet. Once an initial module or modules are delivered to the user, the application begins to execute while additional modules are streamed in the background. The modules are streamed to the user in an order which is selected to deliver the modules before they are required by the locally executing software. The sequence of streaming can be varied in response to the manner in which the user operates the application to ensure that needed modules are delivered prior to use as often as possible. To reduce streaming time, the size of code files, such as library modules, can be reduced by substituting various coded procedures with shortened streaming xe2x80x9cstubxe2x80x9d procedures which act as link-time substitutes for the removed code. Suitable modules to replace are those which are not required for the initial execution of the application. As the application is running locally on the client, additional modules are streamed to the client and the stub code can be dynamically replaced as the substituted procedures are received. The stub procedure can point to a streaming engine which will request a missing procedure if the program calls it before it has been received at the client.
Although effective, the stub-code substitution technique used in the xe2x80x9cStreaming Modulesxe2x80x9d system may require a reasonable degree of processing to prepare a given application for streaming. In addition, the client software required to manage the streamed modules does not necessarily integrate cleanly with the normal routines used by the operating system executing on the client machine.
Accordingly, there is a need to provide streamed applications and supporting streaming management software in a manner which more closely aligns with how a locally running application would actually be loaded and executed.
The present invention is directed to a method, system, and architecture which enables local execution of application programs on a Client computer while delivering the application code and data from a central Server and over a network, such as the Internet, or other data network, such as a wired or wireless TCP/IP Wide Area Network (WAN). The application does not need to be installed on the Client PC. Instead, the application is streamed to the client""s system in streamlets or blocks which are stored in a persistent client-side cache and the system is configured such that the application can begin to execute on the client machine after only a small fraction of the application is loaded.
More specifically, the application to be executed is stored as a set of blocks or xe2x80x9cstreamletsxe2x80x9d (parts into which the application has been divided) on a server. In a preferred embodiment, each streamlet blocks corresponds to a data block which would be processed by the native operating system running on the client system were the entire application locally present. For example, standard Windows systems utilize a 4 k code page when loading data blocks from disk or in response to paging requests. Preferably, each streamlet is stored in a pre-compressed format on the server and decompressed upon receipt by the client.
A set of streaming control modules are installed on the client system and include an intelligent caching system which is configured as a sparsely populated virtual file system (xe2x80x9cVFSxe2x80x9d) which is accessed via a dedicated streaming file system (xe2x80x9cFSDxe2x80x9d) driver. The VFS will appear to the operating system to be a local drive which contains the entire application. However, in practice, only pieces of the various files required for execution of the application may actually be present.
During normal operation of an application, the Windows operating system will periodically generate page faults and associated paging requests to load portions of the application into memory. Standard operating system procedures direct these I/O requests to the proper data device driver for processing. When the streaming application is initialized, the operating system is informed that the relevant data is stored on the VFS drive. Thus, as the streaming application executes and paging or data I/O requests are generated to retrieve require code or data, the operating system will automatically direct it to the FSD driver which then passes it in the proper format to the VFS caching system for processing.
If the requested streamlets are present in the VFS, the data is returned to the operating system and the streaming program continues normal operation. If one or more of the requested streamlet blocks are absent from the VFS, a fetch request is issued to the server for the appropriate streamlet blocks. When the streamlets are returned, they are stored in the VFS and the read or paging request from the operating system is satisfied. Application streamlet data can be persistently stored on the client between sessions such that subsequent uses of the same application will result in an immediate startup. Persistent data can be retained within the client""s VFS itself or an image or snapshot of the VFS can be made and stored elsewhere on the client system, which snapshot can be reloaded into the VFS when needed.
To improve responsiveness of the system when the application is not fully loaded in the cache, a predictive engine can be used on the server. Based upon information gathered from user interaction with the application at issue, a statistical usage model can be built which tracks the order in which users access the various streamlets. When a client starts a streaming application, an initial set of streamlets sufficient to enable the application to begin execution is forwarded to the client. Additional application streamlets can then be actively pushed to the client in accordance with the predictive model and possibly additional data forwarded to the server from the client while the application executes. As a result, many of the needed streamlets will be present in the client-side cache before they are needed.
Advantageously, the present architecture described enables a positive user experience with streamed applications without requiring constant use of broadband data links. In addition, and unlike remote-access application systems, the streaming applications execute on the client machine and server and network resources are utilized for delivery only. As a result, server and network load are reduced, allowing for very high scalability of the server-based application delivery service which can deliver, update and distribute applications to a very large number of users, as well as perform centralized version updates, billing, and other management operations. Furthermore, because the application server does not run application code but only delivers streamlets to the client, it can run on operating systems other than the application target operating system, such as Unix derivatives or other future operating systems, as well as Windows-based servers. In addition, the application streaming system is source code independent. Applications are packaged automatically on the server in accordance with an analysis of the sequence in which the application is loaded into memory during execution. No changes to the application itself are required.
The present invention can be used as an enabling technology for remote application hosting, or application service provision (ASP). As broadband technology for connecting end-users to the Internet becomes more widespread, the advantages of application hosting and provision become more convincing and overpowering. However, since bandwidth limitations are likely to exist for some time, especially when compared to the bandwidth available to a locally executed application, the present invention provides ways to enhance an application delivery and make it more efficient, while at the same time creating a layer of separation between the Client and the Server, enabling much better control over server integrity and security.